• No support for JsonPatches

There are several problems with JsonPatch:

• It is not an associative operation: (base × role-patch) × role-group-patch ≠ base × (role-patch × role-group-patch)
  I would expect that the patch defined at the role level is applied to the base configuration before the patch defined at the role group level is. But the operators are actually implemented to first merge the configOverrides from the role and role group level (where keys in the role group level override those in the role level) and afterwards apply them to the base configuration. As the other variants of configOverrides are associative, this is just an implementation detail, but JsonPatch would produce unexpected results.
• A JsonPatch can fail, the other variants cannot. This poses a problem for the structure in the OpenSearch operator. The validation step should reject an invalid cluster specification. But it cannot be determined beforehand if a patch can be applied. It would fail in the build step, which is currently infallible.
• A JsonPatch highly depends on the base configuration, but the base configuration should be an implementation detail. JsonMergePatch and KeyValueConfigOverrides are more resilient to changes.

I can't think of an OpenSearch setting where a JsonPatch would make sense, but there are a lot of pitfalls, so I would leave it out of the OpenSearch operator. We can also reconsider the decision, especially if the other operators are aligned to the structure of the OpenSearch operator.

The other operators currently only use KeyValueConfigOverrides. Therefore, the users will not recognize that the JsonConfigOverrides are implemented differently in this operator.

The other operators currently only use KeyValueConfigOverrides

OPA uses JsonConfigOverrides, but I'd be fine with dropping JsonPatch there as well. @sbernauer I think you had some use cases for JsonPatch though, not sure. I'm fine with either option (dropping JsonPatch completely or supporting it only for some operators), I see the headaches it can cause (as you explained), just wanted to discuss now explicitly which way we want to go and then maybe update the decision.

UserProvided(Value) instead of UserProvided(String)

To clarify, UserProvided is only used for JSON or YAML files.

Value has the following advantages:

• It ensures that the content is valid JSON/YAML. If a String is used then we have to decide if the operator should try to parse it or if it should just be written as is to the configuration file. In the latter case, it depends on the product how prominently the user is informed or if the error is just ignored.
• What to do if UserProvided(String) is used at the role level and JsonMergePatch at the role group level? They cannot be merged if the string is not parsed in the operator. If it is parsed, then UserProvided(Value) is the better option.

a user can just paste the config in there

There should be no difference between Value and String.

KeyValueConfigOverrides use BTreeMap<String, Option<String>> instead of BTreeMap<String, String> (to delete values?)

This is just an implementation detail. BTreeMap<String, Option<String>> implements Merge by default,
BTreeMap<String, String> does not. I could have written the implementation for Merge manually, but it should make no difference for the user.